Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport from other branches #802

Merged
merged 10 commits into from
Aug 7, 2020
Merged

Conversation

Thrameos
Copy link
Contributor

This is a backport of changes from future branches.

  • Fixes warnings on clang.
  • Removes thunk code and replaces with external jar file.
  • Adds a dynamic class loader to loading classes after the JVM is started.
  • Fixes name conflict on overloaded method.
  • Internal jar is now available regardless of how it was loaded.
  • Adds attach to JVM entry point for starting Python from Java or Android.
  • Native entry points now load automatically rather than being registered manually.

@codecov
Copy link

codecov bot commented Jul 19, 2020

Codecov Report

Merging #802 into master will increase coverage by 9.36%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #802      +/-   ##
============================================
+ Coverage     83.06%   92.42%   +9.36%     
============================================
  Files           142       24     -118     
  Lines         11813     1453   -10360     
  Branches       4454        0    -4454     
============================================
- Hits           9812     1343    -8469     
+ Misses         1248      110    -1138     
+ Partials        753        0     -753     
Impacted Files Coverage Δ Complexity Δ
jpype/_core.py 96.19% <100.00%> (+0.03%) 0.00 <0.00> (ø)
jpype/pickle.py 88.09% <100.00%> (-0.55%) 0.00 <0.00> (ø)
jpype/_jstring.py 96.87% <0.00%> (-3.13%) 0.00% <0.00%> (ø%)
jpype/_jclass.py 98.46% <0.00%> (-0.77%) 0.00% <0.00%> (ø%)
native/common/jp_gc.cpp
native/python/pyjp_char.cpp
native/common/jp_stringtype.cpp
native/common/include/jp_array.h
native/common/jp_primitivetype.cpp
...ative/java/org/jpype/javadoc/JavadocException.java
... and 62 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a40d91...d45baf5. Read the comment docs.

@Thrameos
Copy link
Contributor Author

This is targeting release 1.1.x as it does things to the backend that constitute a substantial change (though it shouldn't be reflected in the API.) It will take a while to get all the bugs out as it touches the boot loader path. After this point we won't have to do special magic to register the native entry points and our jar file will be accessable outside the module (which doesn't do much until I complete the rest of Python from Java patch.)

@Thrameos Thrameos added the enhancement Improvement in capability planned for future release label Jul 22, 2020
@Thrameos Thrameos added this to the JPype 1.1 milestone Jul 22, 2020
@Thrameos Thrameos requested a review from marscher July 24, 2020 13:51
@Thrameos
Copy link
Contributor Author

@marscher This one is finally ready for review. This won't be applied until 1.1 as it is rearranging stuff having to do with thunks. It is a prerequisite for a few future enhancements as it cleans up a bunch of core issues and makes native linking much easier.

jpype/_core.py Outdated Show resolved Hide resolved
@Thrameos
Copy link
Contributor Author

Working to resolve the conflict. Will take a bit as it is a structural difference in the load procedure that needs to be resolved.

@Thrameos
Copy link
Contributor Author

Is this review complete?

@marscher
Copy link
Member

marscher commented Aug 6, 2020

Sorry I've added some points in the meantime.

@Thrameos
Copy link
Contributor Author

Thrameos commented Aug 6, 2020

@marsher So I have added a bunch of PRs that could go in that could form a patch release as well as few that are built on this as a base. I have tried to label which are which by the milestone. If you see something that isn't appropriate for a patch release you can add the milestone to it. So we may need to come up with some other way to indicate it.

In the mean time, I have been trying to identify some of the user needs by soliciting input from some of the other github projects. Bayer-Group/paquo#33 and scijava/scyjava#18. It has given me a few ideas that we may be able to apply.

@marscher marscher merged commit 3f0a518 into jpype-project:master Aug 7, 2020


def read_utf8(path, *parts):
filename = os.path.join(os.path.dirname(path), *parts)
return codecs.open(filename, encoding='utf-8').read()


def find_sources():
def find_sources(roots=[]):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awooga! I just bisected an issue (to be raised shortly) which points back to this commit. I have no idea if the problem is related to this, but I was quickly reviewing the code and saw this. I'm sure you already know about the pitfalls of mutable defaults with Python, and that they are a no-go unless you really intend them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other mutable defaults in Platform appear to have been removed in 1f58b10.

Issue mentioned opened in #848. Unfortunately, fixing this one doesn't seem to address

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement in capability planned for future release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants